DTS Glossary

DTS run ID: A unique identifier of one transformation execution. The run ID covers the transformation scope, any performance tuning and the execution details. The run ID with all its details can be copied for future reuse (also to another system).

DTS run ID type: Represents one of the three main scenarios: Conversion, Deletion or Migration. The scope of the scenario is defined in the content package.

Content package: Contains the solution (software components) and objects (DTS business objects, conversion and filtering rules, derivation paths) for a specific business scenario and predefines the transformation scope, e.g. selective vs. full system copy.

DTS business object (BO): An abstract unit labeled with a name of up to 30 characters and defined by data element(s) and/or domain(s) that typically represents an SAP business object. There are three types of DTS business object:

Standard (S): Set of SAP data elements and domains labeled with a name of up to 30 characters.
InfoObject (I): Like the standard BO but focused on the InfoObjects. This type is relevant for BW and SCM systems only.
Compounding (C): Set of standard BOs. The set gives the final object a unique interpretation, e.g. BELNR – document number and GJAHR – fiscal year. This type is relevant for ERP systems only.

DTS business object table: DTS business objects can also store values. These values are stored in a generated table that is used for data selection during the read tasks. You can enter the values manually or automatically via the DTS derivation paths during the preselection. For more information, see the chapter Setting up the Derivation of DTS Business Object Values. The table structure follows the business object definition:

Standardbusiness object tables have one field of the data element marked with the Default flag in the business object definition.
Compounding business object tables are built from the fields of default data elements of the included DTS business objects.
InfoObject type business object tables are built from the key fields of the assigned business object SID table. For example, if a business object is built on the InfoObject 0COST_ELMNT, the DTS business object table will have the fields co_area and cost_element. These are the same as the key fields in the table /BI0/SCOST_ELMNT.

BO replication: Allows you to copy a business object table from a remote system (typically an ERP system) into the chosen business object in the current setup.

DTS table pool: A list of database tables that will be processed during the transformation. This takes place together with the table fields that are assigned to either DTS rules that are relevant for the transformation or DTS business objects that are relevant for the preselection. DTS builds the table pool automatically (see the step Generate table pool) based on the scenario, active DTS rules and DTS preselection setup. The consistency of the transformation depends on the correctness of the table pool.

Locked table: A table that has a lock flag in the list of tables. Such a table is not processed by the DTS table pool generation or the assignment of a transformation rule/business object. You can lock tables in the step Maintain table pool.

Dependent field or Dependent business object: These are objects that are required in order to apply the DTS rule logic. Most often they are compounding objects. For example, the cost center depends on the controlling area, and the fiscal year depends on the fiscal year variant.

DTS preselection: Preselection is a process that takes place in scenarios with selectivity. During the preselection, the values used for the selection are derived using DTS derivation paths. For more information, see the chapter DTS Preselection.

DTS derivation path: A DTS derivation path is a function between two DTS business objects – the input business object and the output business object. The function can either be based on a table or based on ABAP logic. The outcome of the function is input values of the output business object. For more information, see the chapter DTS Derivation Path.

DTS derivation path table: Each DTS derivation path stores the results of the derivation in its own generated table. If more than one derivation path defines one business object, the values from the path tables are consolidated based on the consolidation settings. For more information, see the chapter Setting up the Derivation of DTS Business Object Values.

The structure of a derivation path table is as follows:

Output business object: Field that represents the output business object.
Input business object: Field that represents the input business object.
Part_rel: One character field that behaves as a flag. Possible values: <empty> = fully relevant; X = partially relevant. Partially relevant is set when the output value belongs to both relevant and not relevant input values.

EXAMPLE The material M1 is assigned to the plants P1 and P2. However, only P1 is relevant for processing based on the input company codes. The material M1 will have this flag set to X.

You can view the values of the derivation path tables in the step Execute and monitor preselection.

Input DTS business object: A BO that is used as the input of a derivation path (function).

Output DTS business object: A BO that is used as the output of a derivation path (function).

DTS rule: A DTS rule is a function that translates the input value (original value from a table) into the changed value. For example, a mapping list of old values to new values. For more information, see the chapter DTS Rules.

Rule assignment: The assignment of a conversion or filtering rule to a specific table and field. There can be more than one rule per field assigned, although a 1:1 assignment is most common.

DTS cluster: A set of tables with data clusters where all the data relevant for the transformation that is selected during the read phase is compressed and stored in dedicated cluster table(s) generated by DTS.

DTS data file: A file with data selected from an SAP system. One file represents one DTS package. The files are organized into folders per table. The table folders are stored in the DTS run ID folder. File usage must be enabled for the DTS run ID. For more information, see the step Maintain run ID.

Transformation task: A transformation task represents an activity unit related to a specific phase in the execution monitor. Each table can have a maximum of one task per phase (read, beam, deletion, conversion and insertion phase). If parallelization is used, one task can have multiple partitions.

DTS execution phase	DTS task type	Parallelization	Description
Preselection	Derivation task	Manual	Task assigned to one DTS derivation path. Can be parallelized.
	Consolidation task	Manual	Task assigned to a business object in the preselection. The task collects the results from all derivation paths that derive the business object.
	Preselection task	Manual	A shared name for the two tasks above
Read	Read task	Manual	Task assigned to a table. The task can be split by DTS partitions. The task selects data from the database and applies the DTS filtering rules or WHERE condition, saves the data as DTS packages in a DTS cluster, and generates DTS partitions in the next tasks (beam, delete, insert).
Read	Delta read task	Manual	Task assigned to a table. The task selects data collected by a DTS delta, saves the data as DTS packages in a DTS cluster, and generates DTS partitions in the next tasks (beam, delta delete, insert).
Beam	Beam task	Automatic	Task assigned to a table. The task transfers the DTS partitions from the source to the target in parallel.
Delete	Delete task	Automatic	Task assigned to a table. The task deletes the DTS partitions in parallel.
Delete	Delta delete task	Automatic	Task assigned to a table. The task deletes the DTS partitions that are marked for deletion by the delta read in parallel.
Insert	Insertion task	Automatic	Task assigned to a table. The task inserts the DTS partitions in parallel.

Parallel read: A bigger table can be split into smaller partitions to enable parallelization during the read process. The table split criteria are set by the DTS user. A good understanding of how database SELECT statements work is important to ensure real runtime optimization.

DTS partition: A task partition defines the number of DTS packages that are processed within a single task. According to the DTS execution phase, there are two types of partition:

Read partition: A read phase partition is a set of data processed by one read task. By default, there is only one read partition (i.e. no read parallelization). You can define the number of read partitions during the parallel read setup. Each partition is processed by its own read task. For more information, see the chapter Setting up the Parallel Read.

Conversion partition: A conversion partition is a set of data split by read task, by DTS package size and by the number of packages in one conversion partition. You can define the number of DTS packages in one conversion partition in the step Maintain technical settings. The default value is 50. The conversion partition is used to parallelize the beam, conversion, deletion and insertion phases. DTS generates one task per partition.

Shadow table:A table that is activated for the NZD scenario. For each table enabled for NZD processing with DB triggers, a shadow table is generated. The shadow table contains the table key, change type and timestamp. All shadow tables are generated with the prefix ZSH*.

Source system: In transformation projects, the source system is the system from which the data relevant for the transformation is selected. Source and target systems are used in all scenarios where data needs to be migrated, e.g. a cloud migration or a carve-out.

Target system: Similar to the source system. The data relevant for the transformation is inserted into the target system.

Execution: A phase of a test cycle (or productive system change) during which the values are changed at the database level. The execution is heavily parallelized and takes almost all the system resources. No activity other than the execution or transformation execution can be running on the system during this phase. See also the term Transformation task above.

System downtime: The execution of the production system(s). The system is locked and no business operations can take place. Only the project team can access the system during the system downtime.

Checkpoint: A checkpoint is a place in the activity tree where checks for confirming the minimum criteria to successfully continue with the following activities must be performed. Checkpoints can be manual or automated.

DTS delta mode: This is how DTS collects changes to already processed data during the uptime migration. For more information, see the chapter DTS NZD Processing.

DTS package: A value given in number of rows that represents one data set processed during one task in the DTS execution. The default value is calculated in the step Analyze technical settings of tables, during which DTS sets the corresponding number of rows to cover a size of 50 MB per DTS package. See also the term DTS partition above.

DTS transfer structure: The structure of the data that is used for storing data processed by DTS. Most often this is equal to the processed table structure. In some cases, it can be shortened for performance improvement or extended by new field(s). For more information about extending the transfer structure, see the chapter DTS Transfer Structure Editor.